Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AD: Ignore Foreign Security Principals in groups #7596

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

ondrejv2
Copy link
Contributor

Currently, group enumeration fails when group contains Foreign security principals.
This code silently ignores them since we can't resolve these anyway (at least ATM).

@alexey-tikhonov alexey-tikhonov added the no-backport This should go to target branch only. label Sep 16, 2024
@@ -34,7 +34,7 @@ SSS_IDMAP_0.4 {
sss_idmap_free_smb_sid;
sss_idmap_free_bin_sid;
idmap_error_string;
is_domain_sid;
is_str_sid;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi,

it is not recommended to change the API of a released library. Please move is_domain_sid() and is_principal_sid() to sss_idmap.c and add is_principal_sid() and if you like is_str_sid() to a new library version SSS_IDMAP_0.5.

bye,
Sumit

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi,

it is not recommended to change the API of a released library. Please move is_domain_sid() and is_principal_sid() to sss_idmap.c and add is_principal_sid() and if you like is_str_sid() to a new library version SSS_IDMAP_0.5.

bye, Sumit

Can't we just move (for backward compatibility) the is_domain_sid() function? I mean is_principal_sid() can stay as inline in sss_idmap.h right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi,
it is not recommended to change the API of a released library. Please move is_domain_sid() and is_principal_sid() to sss_idmap.c and add is_principal_sid() and if you like is_str_sid() to a new library version SSS_IDMAP_0.5.
bye, Sumit

Can't we just move (for backward compatibility) the is_domain_sid() function? I mean is_principal_sid() can stay as inline in sss_idmap.h right?

Hi,

I have to admit that do not like code in header files that much. I know there are a few examples in the SSSD code. But libsss_idmap is a library used by other projects as well and I would prefer to make it clear that a call part of the API or not. So I would like to encourage you to add is_principal_sid() to sss_idmap.c as well. If you think that is_principal_sid() does not belong into libsss_idmap I would suggest to just add it to sdap_async_nested_groups.c as a macro calling is_str_sid().

bye,
Sumit

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi,

thank you, this looks good now. I just got mixed up with the version numbers SSS_IDMAP_0.5 is the current one. So can you please mofify the change of sss_idmap.exports to

--- a/src/lib/idmap/sss_idmap.exports
+++ b/src/lib/idmap/sss_idmap.exports
@@ -64,3 +64,12 @@ SSS_IDMAP_0.5 {
         sss_idmap_add_auto_domain_ex;
 
 } SSS_IDMAP_0.4;
+
+SSS_IDMAP_0.6 {
+
+    # public functions
+    global:
+
+        is_principal_sid;
+
+} SSS_IDMAP_0.5;

Finally I would like to suggest to add fspdn_len to group_ctx->opts->sdom as well so that strlen(fspdn) has to be calculated only once.

bye,
Sumit

src/providers/ldap/sdap_async_nested_groups.c Outdated Show resolved Hide resolved
src/providers/ldap/sdap_async_nested_groups.c Outdated Show resolved Hide resolved
src/providers/ldap/sdap_async_nested_groups.c Outdated Show resolved Hide resolved
src/providers/ldap/sdap_async_nested_groups.c Outdated Show resolved Hide resolved
src/providers/ldap/sdap_async_nested_groups.c Outdated Show resolved Hide resolved
src/providers/ldap/sdap_async_nested_groups.c Outdated Show resolved Hide resolved
@alexey-tikhonov alexey-tikhonov added branch: sssd-2-10 and removed no-backport This should go to target branch only. labels Oct 22, 2024
@alexey-tikhonov
Copy link
Member

This also need a proper commit message, including a release note (see https://github.com/SSSD/sssd/blob/master/.git-commit-template#L7)

@ondrejv2
Copy link
Contributor Author

Hello,
I just added another commit which is actually independent of the others and offers another solution of the problem.
In my opinion, it is actually better because:

  • it is bullet proof (Foreign security principals are detected regardless of the location)
  • it is simpler
  • it offers a good starting point for following Foreign security principals in the future

one disadvantage:

  • it requires extra ldap search (but we are doing it atm, anyway)

Please consider

@sumit-bose
Copy link
Contributor

Hi,

please fix

Trailing whitespace found:
../src/providers/ldap/sdap_async_nested_groups.c:278:       /* we need to populate the sys_name in the user map so the user is recognized later on */ 
FAIL src/tests/whitespace_test (exit status: 1)

bye,
Sumit

@ondrejv2
Copy link
Contributor Author

Hi,

please fix

Trailing whitespace found:
../src/providers/ldap/sdap_async_nested_groups.c:278:       /* we need to populate the sys_name in the user map so the user is recognized later on */ 
FAIL src/tests/whitespace_test (exit status: 1)

bye, Sumit

Fixed, thanks for FYI

@@ -1912,8 +1939,7 @@ sdap_nested_group_lookup_user_send(TALLOC_CTX *mem_ctx,
/* search */
subreq = sdap_get_generic_send(state, ev, group_ctx->opts, group_ctx->sh,
member->dn, LDAP_SCOPE_BASE, filter, attrs,
group_ctx->opts->user_map,
group_ctx->opts->user_map_cnt,
NULL, 0,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi,

why is it needed to remove the map here?

I think this approach is good as well, but you are doing too many shortcuts with this patch.

Imo it would be better to handle the FSPs in sdap_nested_group_lookup_unknown_send()/recv() by adding a dedicated sdap_nested_group_lookup_fsp_send()/recv() request to handle FSPs in the same way as plain user and group members.

bye,
Sumit

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi,
We can't use maps for ldapsearch with multiple object classes in the filter due to the design limitation. I wanted to use single ldap search when detecting FSPs/users. To me it's unnecessary to introduce another sdap_nested_group_lookup_fsp_send()/recv() as it would mean another pointless ldapsearch.
Since we only require member uid at this stage, there is no real need for maps and we can squeeze both searches into single one.
Ondrej

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi,

I see your point. But following this thought would mean to refactor sdap_nested_group_lookup_unknown_send()/recv() to only send a single ldapsearch which would allow all objectclasses (or at least user, group and fsp) and determine the type of the results based on the objectclass. What do you think?

bye,
Sumit

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi,
Well, yes, that would be an ideal case (as the current code is bit "cumbersome") yes.
The problem is, that in order to search for all objectclasses we need to use unmapped search (I've mentioned this in a different PR).
Using unmapped search means sdap_parse_entry() will not map entries for us so we gotta do it manually. Now I did it for the user objectclass as it's not a big deal (single attr uid), but not sure what we need for group objectclasses.

Ondrej

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi,

you can just request all attributes and run sdap_parse_entry() after the type is known based on the objectclass. There is an example how it can be done in sdap_asq_search_parse_entry().

bye,
Sumit

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, but sdap_parse_entry() needs sdap_msg parameter, where do I get it from group_ctx?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi,

instead of using sdap_get_generic_send() you can use sdap_get_generic_ext_send() and add your own parser as a callback. This callback will receive sdap_msg.

HTH

bye,
Sumit

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi,
Sorry, that's bit too complex for me. Can you suggest a suitable code? I can't figure out myself.
Ideally I would like to parse attributes in sdap_nested_group_lookup_unknown_recv() if that's possible.
Namely I need better replacement of this snippet:

       ret = sysdb_attrs_get_string(*_entry, state->group_ctx->opts->user_map[SDAP_AT_USER_NAME].name, &val);
       if (ret != EOK) {
          DEBUG(SSSDBG_TRACE_ALL, "Unable to get username for %s\n",val);
          goto done;
       }
       /* we need to populate the sys_name in the user map so the user is recognized later on */
       sysdb_attrs_add_string(*_entry, state->group_ctx->opts->user_map[SDAP_AT_USER_NAME].sys_name, val);

Once I have the parsing done, then I could possibly do the rest myself.
Thanks.
Ondrej

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants